Hey @MaciejMierzwa, validation of the peer certificate's dn (distinguished name) should be wholly encapsulated within the security plugin. This setting helps mTLS between opensearch node <-> extension node be more secure by verifying that the extension's certificate (peer certificate) matches a list of known distinguished names and if not, deny the transport request as coming from an unknown origin.

Take a look at this method here which is used on the receiving end of a transport request (SecurityRequestHandler) to determine if a transport request has originated from another node within the cluster (intra-cluster request) or from another cluster that is trusted (cross-cluster request where nodes share same root ca)

That method uses the DefaultInterClusterRequestEvaluator.isInterClusterRequest which compares the peer certificates dn with the static list of node_dns in opensearch.yml and from the dynamic list of node_dns in the security index (sourced from the nodes_dn.yml file)

The logic in particular that is interesting is this condition here where it extracts the principal (dn) from the peer certificate and checks if it matches any known node_dns.

The alternative to matching exactly the distinguished name is for the peer certificate to have a known OID (Object Identifier) and then it doesn't need to match a known node_dn. More details about that can be found here. I am a little weaker on the subject alt names and how to properly issue certs with matching OIDs so that an exact node_dn match does not need to occur. I believe its added for convenience to prevent needing to add new node_dns every time a new certificate has been issued when nodes are added to the cluster and instead as long as they share the OID from the subjectAltName its granted permission to join the cluster.

Hi @cwperks thank you for reply. I spent some time debugging the flow. The issue I'm thinking about right now is that during handshake list of DNs is loaded from file or index. (like you mentioned).
Current implementation sends this data in json body in request since design moved away from static config so this data is not available during initial transport request. I'm thinking about maybe loading this info into the index config at first stages of calls. For example around this place: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/extensions/ExtensionsManager.java#L294C29-L294C29. Then this info could be used during handshake and during consecutive calls between extension and cluster.
Let me know what do you think about it